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/htm... (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
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/htm...
(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
Hi Konstantin,
Debugging login issues between SSD, PAM, and AD is not for the faint of heart. In my case I set up Samba 4.3 as a primary AD DC. I could login with Windows 10 guests but not C8.
I just did the following. 1. I spun up a fresh C8 VM, did not add any users, selected a graphical desktop. 2. I added a new user into my AD domain (the one being served by Samba4) 3. When my VM booted, the "first boot" screen appeared. As I went through the steps, when it prompted me to add a user, I clicked on "Configure Enterprise Login" 4. The system automatically found my domain name. I entered the username/password I created. 5. The system prompted for the Domain Admin password, which I entered it. 6. After a few seconds. everything was set up, and I could ssh in to the box in question using the following (keeping in mind that capitalization is important, especially when it comes to AD domain names!):
ssh -l joey@MY-DOMAIN.AS authtest-el8
I was able to login using this procedure. You might try the same thing, and then compare your pam, sssd, and krb5 config files with the fresh VM and the VM you are trying to get working.
-JK
On Tue, Mar 30, 2021 at 7:01 AM Konstantin Boyandin via CentOS < centos@centos.org> wrote:
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/htm...
(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@centos.org https://lists.centos.org/mailman/listinfo/centos
On Mon, Mar 22, 2021 at 11:10 PM Konstantin Boyandin via CentOS centos@centos.org wrote:
I joined a CentOS 8 box to an AD, using the below document as general guide:
How general? Can you describe what you've done that differed from the guide?
When I comment a line in /etc/pam.d/password-auth (the one commented below), error goes away: #account [default=bad success=ok user_unknown=ignore] pam_sss.so
Have you checked /var/log/audit/audit.log for AVCs during login? I suspect an SELinux error.
$ cat /etc/krb5.conf [libdefaults] default_ccache_name = KEYRING:persistent:%{uid}
Specifically, I thought that sssd defaults to KCM storage for kerberos credentials, not the kernel keyring. You might be seeing an SELinux deny due to non-default ccache storage.
On Apr 4, 2021, at 14:08, Gordon Messmer gordon.messmer@gmail.com wrote:
$ cat /etc/krb5.conf [libdefaults] default_ccache_name = KEYRING:persistent:%{uid}
Specifically, I thought that sssd defaults to KCM storage for kerberos credentials, not the kernel keyring. You might be seeing an SELinux deny due to non-default ccache storage.
Only if sssd-kcm is installed. Otherwise the keyring is default. I normally use the keyring on my systems. No selinux issues there.
-- Jonathan Billings
On 3/23/21 12:09 AM, 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/htm... (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]
"System error" generally means an error internally to sssd. I would turn up sssd debugging and check the sssd logs in /var/log/sssd. Also, you'll probably get better support on the sssd list.
On 05.04.2021 08:19, Orion Poplawski wrote:
On 3/23/21 12:09 AM, 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/htm...
(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]
"System error" generally means an error internally to sssd. I would turn up sssd debugging and check the sssd logs in /var/log/sssd. Also, you'll probably get better support on the sssd list.
Thanks for this and previous responses. I am trying to determine whether to look for further; as soon as I figure out where to look at, I could ask for more details (here, in sssd and/or Samba lists).