'sudo su' Permission Denied, but relogging fixes it

I am having an issue that is only present since about April after updating packages. When I am accessing servers and use sudo su or sudo -s to access root and enter my password, I'll get: sudo: PAM account management error: Permission denied \ sudo: a password is required However, when I exit and restart the SSH session, it works fine. This a periodic issue and does not happen on all servers at the same time in my environment. I have noticed that the sssd service reports offline sometimes, but is back up and the log timings don't seem to match up with the events. I have turned on base level logging for sssd, but have not seen anything that is inherently apparent as the issue. Any insight would be welcomed. Updates: The failed login attempts trigger several PAM modules in sssd_pam.log and ends in this:

[pam] [pam_reply] (0x0200): [CID#9] blen: 24
[pam] [pam_reply] (0x0200): [CID#9] Returning : Permission denied to the client
[pam] [client_recv] (0x0200): [CID#9] Client disconnected!

A successful login attempt just triggers twice, SSS_PAM_PREAUTH and once SSS_PAM_AUTHENTICATE and results in this when using sudo:

[pam_reply] (0x0200): [CID#10] blen: 24
[pam] [pam_reply] (0x0200): [CID#10] Returning : Success to the client
[pam] [pam_cmd_acct_mgmt] (0x0100): [CID#10] entering pam_cmd_acct_mgmt

While speaking of PAM, worth noting that I have compared PAM configurations from lowers where this is occurring to PROD where it is not present and they are identical, the only change I found yesterday was a smartcard auth rpm file, which I deleted, but that, as expected, did not change this behavior. More updates: /var/log/secure shows that the same sudo:auth success message leads to two different results. The failed:

pam_sss(sudo:auth): authentication success; logname=xxxx uid=XXXX euid=0 tty=/dev/pts/0 ruser=xxxx rhost= user=xxxx
pam_sss(sudo:account): Access denied for user xxxx: 6 (Permission denied)

The success:

pam_sss(sudo:auth): authentication success; logname=xxxx uid=XXXX euid=0 tty=/dev/pts/0 ruser=xxxx rhost= user=xxxx
pam_unix(sudo:session): session opened for user root by xxxx(uid=xxxx)

I found a configuration difference that may prove useful - /etc/pam.d/systemd-user seems to have a line in non-effected environments that is not present in affected environments:

session  optional pam_keyinit.so force revoke

I'm not familiar with this configuration option so I'm doing some research on it and implementing it, once it's in place I'll try to replicate the issue, but after a session is restarted(in order to reach root to make the change) it can take a while to present. Latest Update: I found a line that, upon investigation, doesn't appear to indicate that it would cause this kind of behavior, but I have not been able to reproduce the error since removing this line from /etc/pam.d/login

session    optional     pam_console.so