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
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
https://lists.centos.org/mailman/listinfo/centos
