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.
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.
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.
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.
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?
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.
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
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.
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)
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.
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.
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.