OOD with OIDC login is failing. The user account does exist in the environment, but when the user tries to login they get this message:
error – can’t find user
I am pretty new to ood, and would deeply appreciate any help getting past this issue so that the user can access the environment.
Hi and welcome!
So what’s happening is we’re trying to map the user from the OIDC system to the local system. The fact that there’s no user there in the message is a clue (it should specify the user like error – can’t find user ktrout).
So that leads me to believe you’re mapping the REMOTE_USER to an empty string. The setting from the OIDC docs you’re looking for is oidc_remote_user_claim. I would guess that it defaults to preferred_username (a quick glance/spot check confirmed this).
So - either the user has no preferred_username (or it’s an empty string) or you’ve set oidc_remote_user_claim to a value that the OIDC system does not have.
https://osc.github.io/ood-documentation/latest/authentication/oidc.html
Additionally - you can set the lua_log_level to debug and you’ll see messages about how we’re mapping the REMOTE_USER.
Though you’re likely to just see messages that say what we already know like
mapped user johrstrom@osc.edu => ''
I apologize - I omitted part of the error message to not include the username. You are correct that the error message looks more like this:
Error – can’t find user for myuser
Run ‘nginx_stage --help’ to see a full list of available command line options.
Does this error indicate that there is an issue mapping the user from the OIDC system to the local system?
OK - let’s use myuser as the example. It appears that myuser is not a local/LDAP system user.
If you have a shell session on the webnode can you issue id myuser (replacing myuser with your actual user). This spot check should tell us if the user is available locally. I would guess that it isn’t.
That said - what version and OS are you running? I do know there’s an issue with 2.0 (maybe 1.8?) and less with some SSSD mappings.
Hi, the OOD version is 2.0.29 and the OS is CentOS 7.9. The user is available locally since the output of id myuser looks something like this:
id myuser
uid=NUMBER (myuser) gid=NUMBER (group1) groups=NUMBER (group1), NUMBER (group2)
note - in this case NUMBER is being used to omit the actual values of the uid/gids associated with the user locally.
As root, I can also su as the user in the local environment.
OK - I would say increase the lua_log_level to debug in ood_portal.yml and see what the messages around mapping are.
You should see something like this in your /var/log/httpd-httpd24/ logs.
mapped user johrstrom@osc.edu => 'myuser'
I’m also wondering if you’re running into this issue. Looks like we patched it in 2.0.23 - but it appears to be running this after you’ve initialized the user. You can look through this topic on strategies to debug in irb, but the TLDR is that the SSSD configs aren’t quite right (they keep the domain on the username).
Hey Jeff,
After reviewing the linked issue. I recalled a peculiarity about the user that is facing the problem I reported. All of the users in the environment have a username that looks like this:
firstname.lastname
However, the user in question had a fairly long name and reached a character limit in the OOD environment. Consequently, his user account is more like this:
firstname.lastn
Essentially, we omitted the last few characters from his username. I suspect that what is going on is that when the user tries to auth via oidc, OOD is expecting firstname.lastn for the username and instead it’s getting something like: firstname.lastname.
What would you recommend that I do to confirm that this is what is happening, and how can I ensure that OOD can map the user appropriately?
You’ve been omitting the names throughout this thread - but to confirm this is what happening, I’d spot check the error message. It should look like this: I.e., the full string with lastname completely.
error – can’t find user for username.lastname
What OIDC system are you using and are you able to change this users’ preferred_username attribute? I think that would be the simplest/straight forward thing to do. (perhaps you can edit the same field in LDAP?)
Forcing your OIDC system to return firstname.lastn instead of firstname.lastname is the best bet here, otherwise you’re going to get a bit hacky to take care of this edge case, which I can tell you, but I’d like to try this first.