"Bad Request Unregistered redirect_uri" from Dex with LDAP

I have installed Open OnDemand 4.0.0 and am trying to configure authentication with Dex and LDAP. I modified ood_portal.yml based on the example at
https://osc.github.io/ood-documentation/latest/authentication/dex.html#configuring-ondemand-dex-for-ldap
ran update_ood_portal, and restarted ondemand-dex.service and httpd. Connecting to http://simple_hostname/ generates a page saying

Bad Request
Unregistered redirect_uri (“http://simple_hostname/oidc”).

In the apache access_log I found a message

GET /dex/auth/ldap?client_id=…

with a 400 response code, which maps to “Bad Request”, so this seems to indicate a problem with LDAP. Using command line tool ldapsearch, I have verified that the host can reach the LDAP service and that the bind credentials are correct. I have not yet installed a digital certificate on Apache and have disabled SELinux temporarily.

Do I have a likely LDAP configuration error, or am I trying to do something too soon before completing other steps?

Hi, sorry for the delay in the response. Can you share your ood_portal.yml obfuscating anything you need. I’m trying to see if there’s some misconfiguration you’ve got. It seems like it should populate things automagically, but if you’re overriding something, then it’ll use that value instead.

Greetings, Jeff,

Thank you for the response. The delay is okay; I nave multiple balls in the air myself.

I have attached my ood_portal.yml to this message; please tell me if it does not reach you for some reason, such as being stripped by our mail system.

Here are some notes about what you will see.

  • I have changed the bind CN, but the rest of the DN is correct. Of course, I have obfuscated the bind password.

  • For userSearch, our LDAP is a view into Microsoft Active Directory, where we have nested groups, so the “filter” has a form that flattens the nested structure for LDAP searches. If you are interested, I can send you a reference. This form does work with ldapsearch on a command line, and we have used it other places. Again, the CN for the group is obfuscated, but the rest of the DN is correct.

  • For groupSearch, our directory does not have attribute “posixGroup”, so I left that filter unchanged. Certainly, that could be a problem.

Regards,

Eric

(attachments)

ood_portal.yml (15 KB)

I don’t think it’s an issue with your LDAP configurations.

My best guess without replicating is there’s some issue on our side with regard to defaults. For example, setting servername here may be important. You don’t have that set, so there could be some mismatch because you don’t have it configured.

I’m looking to replicate in a container now.

Greetings, Jeff,

That is interesting. This may become a factor when we install a digital certificate because we will use a virtualhost name with that. The actual server name is a user-unfriendly name assigned from a facilities viewpoint.

Regards,

Eric

Yes I was able to replicate this when I modified the config file.

These 2 values need to be the same, and it appears they’re not given this default.

This appears to be relative in /etc/ood/config/ood_portal.conf.

OIDCRedirectURI /oidc

And in /etc/ood/dex/config.yml theres this snippet:

- id: short-hash
  redirectURIs:
  - http://simple_hostname/oidc
  name: OnDemand
  secret: some-hash-value

Something about this default doesn’t quite work. What is the exact redirectURIs for your dex configurations? It may be keeping the port number in the URL and that’s what’s wrong?

Greetings, Jeff,

In /etc/ood/dex/config.yaml I have FQDNs:

staticClients:

  • id: hostname.mdanderson.edu

redirectURIs:

name: OnDemand

although command hostname returns simple name.

Regards,

Eric

OK - then I would set the servername property in ood_portal.yml and see if that’s any different. Since it seems to be the simple name - that’s what apache’s sending, so it seems like you need to specify the FQDN in the servername.

Greetings, Jeff,

That gives me the login page, finally. However, when I enter my username and password, I am presented with message

Error – sudo: PAM account management error: Permission denied

sudo: a password is required

Does user ondemand-dex require sudo permission for some action?

Regards,

Eric

Greetings, Jeff,

Actually, it appears that “apache” is the offend

ing user, from /var/log/secure:

Feb 3 16:10:18 hostname sudo[398402]: pam_access(sudo:account): access denied for user apache' from

Feb 3 16:10:18 hostname sudo[398402]: pam_sss(sudo:account): Access denied for user apache: 10 (User not known to the underlying authentication module)

Feb 3 16:10:18 hostname sudo[398402]: apache : PAM account management error: Permission denied ; PWD=/ ; USER=root ; COMMAND=/opt/ood/nginx_stage/sbin/nginx_stage pun -u emsisson -a http%3a%2f%2fhostname.mdanderson.edu%3a80%2fnginx%2finit%3fredir%3d%24http_x_forwarded_escaped_uri

Regards,

Eric

I’m also getting this in an el9 container, though I don’t know why.

Do you have selinux turned on without ondemand-selinux installed? @tdockendorf any other ideas?

I disabled SELinux before installing Open OnDemand, and it still is in Permissive mode. Later, I intend to restore it to Enforcing mode and install ondemand-selinux.

If it makes any difference, my server is running RHEL 8.10.

Regards,

Eric

Can you confirm you have a sudo rule for apache in /etc/sudoers.d/ood (I want to say that’s the right path, but could be wrong as I pulled it from memory)

That file exists and has the following contents:

Defaults:apache !requiretty, !authenticate

Defaults:apache env_keep += “NGINX_STAGE_* OOD_*”

apache ALL=(ALL) NOPASSWD: /opt/ood/nginx_stage/sbin/nginx_stage

Cmnd_Alias KUBECTL = /usr/local/bin/kubectl, /usr/bin/kubectl, /bin/kubectl

Defaults!KUBECTL !syslog

File /opt/ood/nginx_stage/sbin/nginx_stage exists and is executable:

ls -l /opt/ood/nginx_stage/sbin/nginx_stage

-rwxr-xr-x. 1 root root 844 Dec 30 12:41 /opt/ood/nginx_stage/sbin/nginx_stage

OK - I’m finding there must be something wrong on our side.

When I get a blank EL9 container and install sudo into it - sudo ls -l works just fine. However, the EL9 container I’m using to test OnDemand breaks this. It’s not clear why, but clearly it’s something that we’ve done that throws this off.

Thanks for the update. I will await further information.

Actually scratch that, I can replicate without OnDemand, sorry for indicating I can.

I can replicate the issue as simply as this:

FROM rockylinux/rockylinux:9

RUN dnf install -y sudo && dnf -y update

Running this container (image named sudo:test) reproduces this issue.

podman run --rm -it sudo:test sudo ls -lrta

The dnf update is the important bit. Without it this works, with the dnf update, this is broken. I see pam-1.5.1 being installed along with other utilies like shadow-utils-2:4.9-10.

Googling pam broken sudo broken appears to have several hits. I wonder if you can downgrade PAM? I can’t in my container, the older versions aren’t there anymore.

As I said, this server is running RHEL 8.10; here are the PAM RPMs:

fprintd-pam-1.90.9-2.el8.x86_64

pam-1.3.1-36.el8_10.x86_64

systemd-pam-239-82.el8_10.3.x86_64

Yea, sadly I can replicate with this EL8 container as well.

FROM rockylinux/rockylinux:8

RUN dnf install -y sudo && dnf -y update

OK strange, I went to file a bug on the Rocky Linux page, and while I can replicate the issue with podman (running rootless containers) I cannot replicate with the same image in docker.