6

I've got a default SSSD configuration with PAM. I can login fine as any LDAP user. However, when I create a local user on a server:

adduser test1
passwd test1

and then try to login as that user I get the following error:

pam_sss(sshd:account): Access denied for user test1: 10 (User not known to the underlying authentication module)

My /etc/nsswitch.conf is this:

passwd:     files sss
shadow:     files sss
group:      files sss

#hosts:     db files nisplus nis dns
hosts:      files dns  

bootparams: nisplus [NOTFOUND=return] files

ethers:     files
netmasks:   files
networks:   files
protocols:  files
rpc:        files
services:   files sss

netgroup:   files sss

publickey:  nisplus

automount:  files ldap
aliases:    files nisplus

sudoers: files sss

Now files is listed as an alternate in nsswitch.conf but it doesn't seem to be looking at the files to authenticate.

How can I allow login as a local user when SSSD is my authentication module?

Ramhound
  • 44,080
user3063045
  • 268
  • 1
  • 3
  • 13

6 Answers6

1

Sounds strange. You should look in your pam configuration, in the lines starting with account. I suppose that there is only pam_sss but not pam_unix.

To find the right pam file scould be tricky, depends on the distribution you use.

For RHEL based system and SSH it is /etc/pam.d/password-auth

Ramhound
  • 44,080
sterni1971
  • 31
1

Troubleshooting Authentication, Password Change and Access Control In order for authentication to be successful, the user information must be accurately provided first. Before debugging authentication, please make sure the user information is resolvable with getent passwd $user or id $user. Failing to retrieve the user info would also manifest in the secure logs or the journal with message such as:

pam_sss(sshd:account): Access denied for user admin: 10 (User not known to the underlying authentication module)

Source of Information

Mohit Malviya
  • 143
1

When I got this error, the problem ended up being that the secondary auth (yubikey in my case) should have been listed before unix auth in /etc/pam.d/common-auth but I had put it at the end. Might not apply to your situation, but worth checking

Dion Steel
  • 11
0

I ran into a similar issue to @DionSteel in that I am using YubiKey for 2-factor authentication for my LDAP users (but not for local users).

I'm running CentOS 7, so the file I was dealing with is /etc/pam.d/sshd.

Originally I had the following in my auth section:

#%PAM-1.0
auth       required     pam_yubico.so ...
auth       required     pam_sepermit.so
#auth       substack     password-auth
auth       include      postlogin
# Used with polkit to reauthorize users in remote sessions
-auth      optional     pam_reauthorize.so prepare

password-auth is commented out because I use SSH key authentication rather than password authentication.

I had to restructure things to allow local users to also SSH in to the machine.

#%PAM-1.0
auth       required     pam_sepermit.so
auth       sufficient   pam_yubico.so ...
auth       substack     password-auth
auth       include      postlogin
# Used with polkit to reauthorize users in remote sessions
-auth      optional     pam_reauthorize.so prepare

First, I made my YubiKey authentication sufficient rather than required. This means that if it and any previously listed auth modules are successful, the user will immediately be authenticated and no further auth modules will be checked. If it fails, then PAM will ignore it and move on to any further auth rules.

Because of this, I had to move all my other required modules to be before the YubiKey authentication. Hence, I moved auth required pam_sepermit.so up to be on the first line.

Finally I un-commented the password-auth line so that local users could authenticate with passwords in the case that YubiKey authentication fails (which it will for my local users).

Mattman
  • 1
0

I had this issue when I unjoined and rejoined a node to the AD.

The resultant sssd.conf had this line access_provider = simple

The correct config is access_provider = ad

user1285062
  • 1
0

I booted up into recovery mode, managed to run pam-auth-update which noticed that something had been wrongly edited in the pam.d directory. (This was after a failed Duo/MFA install) Once I had confirmed the settings, it corrected everything for me and allowed me to login again with local univ and AD users.

jamboNum5
  • 116
  • 1