Do I understand correctly that this problem - is too trivial - isn't in fact CentOS-related - never happened to anyone else ? There are no good explanations as far as I see, to such PAM behavior. I would appreciate advice on where else to ask about this (the mentioned quick fix doesn't look too good). Thanks. Sincerely, Konstantin On 23.03.2021 13:09, Konstantin Boyandin via CentOS wrote: > Hello, > > I joined a CentOS 8 box to an AD, using the below document as general > guide: > > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/integrating_rhel_systems_directly_with_windows_active_directory/connecting-rhel-systems-directly-to-ad-using-sssd_integrating-rhel-systems-directly-with-active-directory > (section 14.1) > > A problem: after I tried to log on via SSH (as an AD user) to the box, > the journalctl gets the below records: > > March 23 12:41:01 sandbox.lan sshd[2262]: pam_sss(sshd:auth): > authentication success; logname= uid=0 euid=0 tty=ssh ruser= > rhost=10.10.0.55 user=username > March 23 12:41:01 sandbox.lan sshd[2262]: pam_sss(sshd:account): Access > denied for user username: 4 (System error) > March 23 12:41:01 sandbox.lan sshd[2262]: Failed password for username > from 10.10.0.55 port 57610 ssh2 > March 23 12:41:01 sandbox.lan sshd[2262]: fatal: Access denied for user > username by PAM account configuration [preauth] > > Quick and dirty fix: > > When I comment a line in /etc/pam.d/password-auth (the one commented > below), error goes away: > ======= /etc/pam.d/password-auth below > auth required pam_env.so > auth required pam_faildelay.so delay=2000000 > auth [default=1 ignore=ignore success=ok] pam_usertype.so > isregular > auth [default=1 ignore=ignore success=ok] pam_localuser.so > auth sufficient pam_unix.so > nullok try_first_pass > auth [default=1 ignore=ignore success=ok] pam_usertype.so > isregular > 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_usertype.so > issystem > #account [default=bad success=ok user_unknown=ignore] pam_sss.so > account required pam_permit.so > > password requisite pam_pwquality.so try_first_pass local_users_only > password sufficient pam_unix.so > sha512 shadow nullok try_first_pass use_authtok > password sufficient pam_sss.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 > ======= /etc/pam.d/password-auth above > > If I understand correctly, the commented line means "account is invalid > by default; if found in SSSD, it's good; if not found - ignore and > proceed". Commenting it is not a good idea, but I can't figure out > what's wrong (according to first line from jornalctl authentication *is* > passed normally). > > Additional data (AD domain in this example is EXAMPLE.COM): > > $ realm list > realm list > example.com > type: kerberos > realm-name: EXAMPLE.COM > domain-name: example.com > configured: kerberos-member > server-software: active-directory > client-software: sssd > required-package: oddjob > required-package: oddjob-mkhomedir > required-package: sssd > required-package: adcli > required-package: samba-common-tools > login-formats: %U > login-policy: allow-realm-logins > > $ cat /etc/sssd/sssd.conf > [sssd] > domains = example.com > config_file_version = 2 > services = nss, pam, ssh > debug_level = 9 > > [domain/example.com] > ad_domain = example.com > krb5_realm = EXAMPLE.COM > realmd_tags = manages-system joined-with-adcli > cache_credentials = True > id_provider = ad > krb5_store_password_if_offline = True > default_shell = /bin/bash > ldap_sasl_authid = SANDBOX$ > ldap_id_mapping = True > use_fully_qualified_names = False > ad_gpo_ignore_unreadable = True > fallback_homedir = /home/%u > access_provider = ad > debug_level = 9 > === end of /etc/sssd/sssd.conf > > $ cat /etc/krb5.conf > includedir /etc/krb5.conf.d/ > > [logging] > default = FILE:/var/log/krb5libs.log > kdc = FILE:/var/log/krb5kdc.log > admin_server = FILE:/var/log/kadmind.log > > [libdefaults] > ticket_lifetime = 24h > renew_lifetime = 7d > forwardable = true > rdns = false > pkinit_anchors = FILE:/etc/pki/tls/certs/ca-bundle.crt > spake_preauth_groups = edwards25519 > default_ccache_name = KEYRING:persistent:%{uid} > default_realm = EXAMPLE.COM > dns_lookup_realm = false > dns_lookup_kdc = true > > > [realms] > EXAMPLE.COM = { > kdc = dc.example.com > kdc = bdc.example.com > admin_server = dc.example.com > } > > [domain_realm] > .example.com = EXAMPLE.COM > example.com = EXAMPLE.COM > === end of /etc/krb5.conf > > GPO cache exists and is properly owned: > ls -al /var/lib/sss/gpo_cache/example.com/ > total 0 > drwx------. 3 sssd sssd 22 Mar 22 14:52 . > drwxr-xr-x. 3 sssd sssd 24 Mar 22 14:52 .. > drwx------. 3 sssd sssd 52 Mar 22 14:52 Policies > > I would appreciate pieces of advice on how to fix authentication issue > without commenting out the pam.d configuration file line. > > Thank you. > > Sincerely, > Konstantin