"Bad Request Unregistered redirect_uri" from Dex with LDAP

Get Help
21

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

22

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?

23

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.

24

You updated the VM through dnf update?

25

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?

26

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

27

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.

28

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.
29

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.

30

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.

31

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.

32

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.

33

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:

$ 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:

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.

34

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.