We have a CentOS 7.7 system which is joined to a Microsoft AD domain using realmd/sssd. Sudo does work perfectly fine for local system users, however when we attempt to use sudo as an Active Directory user (ocftest) we get the following error:

sudo: PAM account management error: Permission denied

We are using the following version of sudo: sudo-1.8.23-9.el7.x86_64.rpm

The user can "ssh" perfectly fine to the system using their password. This issue comes up a few times after a bit of Googling, and commonly refers to adding the following to the "/etc/security/access.conf" file:

+ : ocftest : ALL
- : ALL : ALL

The users group with the same name (although I have tried the user) is present in the "/etc/sudoers.d/salt" file:

%[email protected] ALL=(ALL) ALL

And just for completeness:

cat /etc/pam.d/sudo
auth       include      system-auth
account    include      system-auth
password   include      system-auth
session    optional     pam_keyinit.so revoke
session    include      system-auth

cat /etc/pam.d/sudo-i
auth       include      sudo
account    include      sudo
password   include      sudo
session    optional     pam_keyinit.so force revoke
session    include      sudo

cat /etc/pam.d/password-auth-ac
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        required      pam_faildelay.so delay=2000000
auth        [default=1 ignore=ignore success=ok] pam_succeed_if.so uid >= 1000 quiet
auth        [default=1 ignore=ignore success=ok] pam_localuser.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 1000 quiet_success
auth        sufficient    pam_sss.so forward_pass
auth        sufficient    pam_krb5.so use_first_pass
auth        required      pam_deny.so

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

password    requisite     pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
password    sufficient    pam_unix.so md5 shadow nullok try_first_pass use_authtok
password    sufficient    pam_sss.so use_authtok
password    sufficient    pam_krb5.so use_authtok

password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
-session     optional      pam_systemd.so
session     optional      pam_oddjob_mkhomedir.so umask=0077
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
session     optional      pam_sss.so
session     optional      pam_krb5.so

cat /etc/sssd/sssd.conf
domains = ad.domain.org
config_file_version = 2
services = nss, pam

ad_domain = ad.domain.org
krb5_realm = AD.DOMAIN.ORG
realmd_tags = manages-system joined-with-samba
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
ignore_group_members = False
use_fully_qualified_names = False
fallback_homedir = /home/%u
access_provider = ad
enumerate = True
dyndns_update = False
auto_private_groups = true
ad_access_filter = (&(memberOf=OU=Users,OU=REDACTED,DC=redacted,DC=org))

  • The problem may be that pam_access.so sees ocftest in access.conf as a local user (or group). Since it's actually in AD, you might need to qualify it with the domain name. The only examples I've seen in the wild use the DOMAIN\user format. The UPN [email protected] format might not work because access.conf uses @ to indicate NIS netgroups. Mar 10, 2022 at 22:07

1 Answer 1


Try adding no_access_check to /etc/pam.d/system-auth (which should be a link to /etc/pam.d/system-auth-ac) after the first occurence of account sufficient pam_vas3.so

# cat system-auth-ac
account sufficient  pam_vas3.so no_access_check
  • pam_vas3.so is third-party software and is not used when joining to an AD domain using realmd/sssd. Mar 10, 2022 at 20:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .