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.
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.
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 email@example.com => '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).
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:
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:
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.