# "Bad Request Unregistered redirect\_uri" from Dex with LDAP

**URL:** <https://discourse.openondemand.org/t/bad-request-unregistered-redirect-uri-from-dex-with-ldap/4003>\
**Category:** Get Help\
**Tags:** question\
**Created:** [January 30, 2025, 3:44pm UTC](https://discourse.openondemand.org/t/bad-request-unregistered-redirect-uri-from-dex-with-ldap/4003 "2025-01-30T15:44:17Z")\
**Posts on this page:** 15\
**Page:** 2

<div class="post-metadata">

**Author:** ![emsisson](https://sea1.discourse-cdn.com/flex015/user_avatar/discourse.openondemand.org/emsisson/32/1028_2.png) [@emsisson](https://discourse.openondemand.org/u/emsisson)\
**Post date:** [February 4, 2025, 5:43pm UTC](https://discourse.openondemand.org/t/bad-request-unregistered-redirect-uri-from-dex-with-ldap/4003/21 "2025-02-04T17:43:38Z")

</div>

If it matters, my server is a VM running in VMware.

---

<div class="post-metadata">

**Author:** ![jeff.ohrstrom](https://sea1.discourse-cdn.com/flex015/user_avatar/discourse.openondemand.org/jeff.ohrstrom/32/136_2.png) [@jeff.ohrstrom](https://discourse.openondemand.org/u/jeff.ohrstrom)\
**Post date:** [February 4, 2025, 6:03pm UTC](https://discourse.openondemand.org/t/bad-request-unregistered-redirect-uri-from-dex-with-ldap/4003/22 "2025-02-04T18:03:15Z")

</div>

I don’t think so. I think there’s some issue with PAM+SSSD+kernel.

Is it possible to spin a brand new VM and `dnf update` and see if `sudo` works at all, for anyone?

---

<div class="post-metadata">

**Author:** ![emsisson](https://sea1.discourse-cdn.com/flex015/user_avatar/discourse.openondemand.org/emsisson/32/1028_2.png) [@emsisson](https://discourse.openondemand.org/u/emsisson)\
**Post date:** [February 4, 2025, 6:18pm UTC](https://discourse.openondemand.org/t/bad-request-unregistered-redirect-uri-from-dex-with-ldap/4003/23 "2025-02-04T18:18:49Z")

</div>

Well, sudo does work on this VM for me. I have to login using a personal account and then use sudo to perform any privileged action. Usually, I do

$ sudo /bin/su -

simply to become root, but I also can do (did, just now)

$ sudo more /etc/sudoers

and get output.

---

<div class="post-metadata">

**Author:** ![jeff.ohrstrom](https://sea1.discourse-cdn.com/flex015/user_avatar/discourse.openondemand.org/jeff.ohrstrom/32/136_2.png) [@jeff.ohrstrom](https://discourse.openondemand.org/u/jeff.ohrstrom)\
**Post date:** [February 4, 2025, 6:25pm UTC](https://discourse.openondemand.org/t/bad-request-unregistered-redirect-uri-from-dex-with-ldap/4003/24 "2025-02-04T18:25:30Z")

</div>

You updated the VM through `dnf update`?

---

<div class="post-metadata">

**Author:** ![jeff.ohrstrom](https://sea1.discourse-cdn.com/flex015/user_avatar/discourse.openondemand.org/jeff.ohrstrom/32/136_2.png) [@jeff.ohrstrom](https://discourse.openondemand.org/u/jeff.ohrstrom)\
**Post date:** [February 4, 2025, 6:26pm UTC](https://discourse.openondemand.org/t/bad-request-unregistered-redirect-uri-from-dex-with-ldap/4003/25 "2025-02-04T18:26:23Z")

</div>

Also - may be specific to local users. I assume the user you use is an LDAP account. Are you able to `su` into any of the local accounts in `/etc/passwd`?

---

<div class="post-metadata">

**Author:** ![emsisson](https://sea1.discourse-cdn.com/flex015/user_avatar/discourse.openondemand.org/emsisson/32/1028_2.png) [@emsisson](https://discourse.openondemand.org/u/emsisson)\
**Post date:** [February 4, 2025, 6:42pm UTC](https://discourse.openondemand.org/t/bad-request-unregistered-redirect-uri-from-dex-with-ldap/4003/26 "2025-02-04T18:42:59Z")

</div>

This system is managed by our data center and is patched and rebooted monthly. The most recent session was 8 days ago, Jan. 27.

---

<div class="post-metadata">

**Author:** ![emsisson](https://sea1.discourse-cdn.com/flex015/user_avatar/discourse.openondemand.org/emsisson/32/1028_2.png) [@emsisson](https://discourse.openondemand.org/u/emsisson)\
**Post date:** [February 4, 2025, 6:47pm UTC](https://discourse.openondemand.org/t/bad-request-unregistered-redirect-uri-from-dex-with-ldap/4003/27 "2025-02-04T18:47:42Z")

</div>

Yes, my account is an LDAP account. All user accounts are LDAP accounts. The only accounts in /etc/passwd are system accounts.

Now that I write the above, I recall a vague memory that some actions — like creating cron jobs — require that even system accounts must be added to /etc/security/access.conf. The same may apply to sudo. I have to attend a meeting now, but I will try that when I return and report the result.

---

<div class="post-metadata">

**Author:** ![jeff.ohrstrom](https://sea1.discourse-cdn.com/flex015/user_avatar/discourse.openondemand.org/jeff.ohrstrom/32/136_2.png) [@jeff.ohrstrom](https://discourse.openondemand.org/u/jeff.ohrstrom)\
**Post date:** [February 4, 2025, 6:48pm UTC](https://discourse.openondemand.org/t/bad-request-unregistered-redirect-uri-from-dex-with-ldap/4003/28 "2025-02-04T18:48:44Z")

</div>

OK - even so, I believe the issue is with local users. I wonder exactly how to replicate, but it seems like to go the full path you’d:

- install `httpd` (or just add the `apache` user)
- Add a sudo rule for that user
- Try to use that sudo rule as that local user.

---

<div class="post-metadata">

**Author:** ![tdockendorf](https://sea1.discourse-cdn.com/flex015/user_avatar/discourse.openondemand.org/tdockendorf/32/202_2.png) [@tdockendorf](https://discourse.openondemand.org/u/tdockendorf)\
**Post date:** [February 4, 2025, 8:13pm UTC](https://discourse.openondemand.org/t/bad-request-unregistered-redirect-uri-from-dex-with-ldap/4003/29 "2025-02-04T20:13:58Z")

</div>

Not sure I’m caught up but from the error before I was mentioned:

> pam\_sss(sudo:account): Access denied for user apache: 10 (User not known to the underlying authentication module)

That indicates if there is an `apache` user then there is some issue with pam\_uninx in PAM stack getting this user and instead it’s attempting to find `apache` user via LDAP using SSSD. That is usually caused by the PAM stack looking into pam\_sss before doing pam\_unix which will cause problems for system accounts in PAM. That’s usually define in `/etc/pam.d/sudo`.

---

<div class="post-metadata">

**Author:** ![tdockendorf](https://sea1.discourse-cdn.com/flex015/user_avatar/discourse.openondemand.org/tdockendorf/32/202_2.png) [@tdockendorf](https://discourse.openondemand.org/u/tdockendorf)\
**Post date:** [February 4, 2025, 8:15pm UTC](https://discourse.openondemand.org/t/bad-request-unregistered-redirect-uri-from-dex-with-ldap/4003/30 "2025-02-04T20:15:27Z")

</div>

Also pam\_access usually is added to /etc/pam.d/sshd and not places like /etc/pam.d/sudo or places that would be included in /etc/pam.d/sudo. If you have pam\_access in the stack for sudo then you’ll need to ensure the apache user is allowed by pam\_access.

---

<div class="post-metadata">

**Author:** ![emsisson](https://sea1.discourse-cdn.com/flex015/user_avatar/discourse.openondemand.org/emsisson/32/1028_2.png) [@emsisson](https://discourse.openondemand.org/u/emsisson)\
**Post date:** [February 4, 2025, 8:35pm UTC](https://discourse.openondemand.org/t/bad-request-unregistered-redirect-uri-from-dex-with-ldap/4003/31 "2025-02-04T20:35:18Z")

</div>

Success, finally. I did the following:

- add user apache to /etc/security/access.conf

- add user apache to group sudoers

- add user apache to group wheel

I think that is everything in place; certainly, I tried modifying other thing. I do not know whether all of those are necessary; my next task will be to see whether I can eliminate some of those steps. However, other tasks are demanding my attention right now.

Thank you very much for your patience and assistance. Truly, I appreciate it.

---

<div class="post-metadata">

**Author:** ![emsisson](https://sea1.discourse-cdn.com/flex015/user_avatar/discourse.openondemand.org/emsisson/32/1028_2.png) [@emsisson](https://discourse.openondemand.org/u/emsisson)\
**Post date:** [February 4, 2025, 10:41pm UTC](https://discourse.openondemand.org/t/bad-request-unregistered-redirect-uri-from-dex-with-ldap/4003/32 "2025-02-04T22:41:03Z")

</div>

Greetings, Trey,

Thanks for the follow-up. Our PAM sudo file looks like the following:

auth include system-auth

account include system-auth

password include system-auth

session include system-auth

In system-auth, pam\_access appears only in “account” and precedes pam\_unix and pam\_sss. In all sections of system-auth, pam\_unix precedes pam\_sss consistently. I never have been comfortable modifying PAM configuration files, so I tend to shy away from that course of action.

I did make this work by adding user apache to /etc/security/access.conf. User apache already is in /etc/passwd (that happened automatically with the addition of RPM httpd). Also, I added user apache to groups “wheel” and “sudoers” in /etc/group. These actions have been sufficient to make this work, finally. How many of the manual changes are necessary will be experiments for tomorrow.

---

<div class="post-metadata">

**Author:** ![tdockendorf](https://sea1.discourse-cdn.com/flex015/user_avatar/discourse.openondemand.org/tdockendorf/32/202_2.png) [@tdockendorf](https://discourse.openondemand.org/u/tdockendorf)\
**Post date:** [February 4, 2025, 11:08pm UTC](https://discourse.openondemand.org/t/bad-request-unregistered-redirect-uri-from-dex-with-ldap/4003/33 "2025-02-04T23:08:43Z")

</div>

OnDemand by defaults adds sudo rules for apache to run the necessary commands so the “wheel” and “sudoers” group changes shouldn’t be necessary unless you only allow one or both of those groups to run any sudo command irregardless of other sudo rules.

Generally the way I see pam\_access used is it gates access to the system, ie sshd. So you have something like this:

```auto
$ cat /etc/pam.d/sshd
#%PAM-1.0
auth substack password-auth
auth include postlogin
account required pam_sepermit.so
account required pam_access.so
account required pam_nologin.so
account include password-auth
<SNIP>

```

That way the shared files like `/etc/pam.d/system-auth` just have this:

```auto
auth required pam_env.so
auth [default=1 success=ok] pam_localuser.so
auth sufficient pam_unix.so try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet_success
auth sufficient pam_sss.so forward_pass
auth required pam_deny.so

account required pam_unix.so
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 500 quiet
account [default=bad success=ok user_unknown=ignore] pam_sss.so
account required pam_permit.so

```

So things like sudo and other “local” operations don’t have to go through pam\_access.

---

<div class="post-metadata">

**Author:** ![emsisson](https://sea1.discourse-cdn.com/flex015/user_avatar/discourse.openondemand.org/emsisson/32/1028_2.png) [@emsisson](https://discourse.openondemand.org/u/emsisson)\
**Post date:** [February 10, 2025, 9:12pm UTC](https://discourse.openondemand.org/t/bad-request-unregistered-redirect-uri-from-dex-with-ldap/4003/34 "2025-02-10T21:12:08Z")

</div>

Apologies for the long delay in follow-up.

We are running RHEL 8 here, and system-auth has

account required pam\_access.so

as the first line of the account block. Furthermore, system-auth is included in sudo. In fact, sudo consists entirely of

auth include system-auth

account include system-auth

password include system-auth

session include system-auth

I have done more experimenting to identify the specific changes necessary for me, rebooting the server between each change then flushing browser caches and restarting the browser between changes. Adding user apache to access.conf is the necessary change I must make to get my page in Open OnDemand (after making Jeff’s change to the “server” setting in ood\_portal.yml).

I have access to a RHEL 9 server, and on that system I see that pam\_access.so is absent from system-auth. In fact, pam\_access.so appears only in atd and crond.

I am working now. Thank you all for your help. I appreciate it.

---

<div class="post-metadata">

**Author:** ![system](https://us1.discourse-cdn.com/flex015/uploads/osc/original/2X/b/bae70bd0ed39a3ae769c2108155f4cb3e9da8385.png) [@system](https://discourse.openondemand.org/u/system)\
**Post date:** [August 9, 2025, 9:12pm UTC](https://discourse.openondemand.org/t/bad-request-unregistered-redirect-uri-from-dex-with-ldap/4003/35 "2025-08-09T21:12:20Z")

</div>

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.

[Previous page](https://discourse.openondemand.org/t/bad-request-unregistered-redirect-uri-from-dex-with-ldap/4003.md?page=1)