Description of problem: A new ssd_user fails to authenticate to localhost with min_uid=500, max_uid=999 (aka defaults). From /var/log/secure, it doesn't even seem to reach sssd. ==> /var/log/secure <== ========================== . . Sep 26 11:34:54 dhcp201-210 passwd: gkr-pam: couldn't update the login keyring password: no old password was entered Sep 26 11:35:19 dhcp201-210 sshd[25543]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=localhost.localdomain user=joe1 Sep 26 11:35:21 dhcp201-210 sshd[25543]: Failed password for joe1 from 127.0.0.1 port 41150 ssh2 ========================== Version-Release number of selected component (if applicable): ========================== [root@dhcp201-210 ~]# rpm -q sssd sssd-1.6.1-1.fc16.x86_64 ========================== [root@dhcp201-210 ~]# cat /etc/redhat-release Fedora release 16 (Verne) [root@dhcp201-210 ~]# ========================== How reproducible: All the time Steps to Reproduce: ========================== [root@dhcp201-210 ~]# sss_useradd joe1 ========================== [root@dhcp201-210 ~]# getent -s sss passwd joe1 joe1:*:501:501:joe1:/home/joe1:/bin/bash [root@dhcp201-210 ~]# ========================== [root@dhcp201-210 ~]# passwd joe1 Changing password for user joe1. New password: BAD PASSWORD: it is based on a dictionary word BAD PASSWORD: is too simple Retype new password: passwd: all authentication tokens updated successfully. ========================== [root@dhcp201-210 ~]# ssh -l joe1 localhost joe1@localhost's password: Permission denied, please try again. joe1@localhost's password: ========================== Actual results: Fail to authenticate, Expected results: Authentication should succeed Additional info: [1] snip of 'sssd.conf' ==================== . . [domain/LOCAL] description = LOCAL Users domain id_provider = local auth_provider = local enumerate = true min_id = 500 max_id = 999 #min_id = 1000 #max_id = 1999 debug_level = 9 . . ==================== [2] system-auth ==================== [root@dhcp201-210 ~]# cat /etc/pam.d/system-auth #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth sufficient pam_fprintd.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 1000 quiet auth sufficient pam_sss.so use_first_pass auth required pam_deny.so account required pam_unix.so 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 required pam_permit.so password requisite pam_cracklib.so try_first_pass retry=3 type= 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 [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so [root@dhcp201-210 ~]# ==================== NOTE: Changing the min_id and max_id to 1000 and 1999 ; restart sssd ; add user and ssh to localhost succeeds
(In reply to comment #0) > Description of problem: > A new ssd_user fails to authenticate to localhost with min_uid=500, max_uid=999 > (aka defaults). From /var/log/secure, it doesn't even seem to reach sssd. > [domain/LOCAL] > description = LOCAL Users domain > id_provider = local > auth_provider = local > enumerate = true > min_id = 500 > max_id = 999 > #min_id = 1000 > #max_id = 1999 > debug_level = 9 > . OK, so there are two issues, really: 1) the example config in the SSSD tree uses min_id and max_id. I don't think it should, the code enforces a different min_id value for local domain and "regular" domains. 2) now that shadow-utils defaults to min_id of 1000, we might consider bumping up the local default to something bigger to avoid immediate clashes with shadow users.
(In reply to comment #1) > (In reply to comment #0) > > Description of problem: > > A new ssd_user fails to authenticate to localhost with min_uid=500, max_uid=999 > > (aka defaults). From /var/log/secure, it doesn't even seem to reach sssd. > > [domain/LOCAL] > > description = LOCAL Users domain > > id_provider = local > > auth_provider = local > > enumerate = true > > min_id = 500 > > max_id = 999 > > #min_id = 1000 > > #max_id = 1999 > > debug_level = 9 > > . > > OK, so there are two issues, really: > > 1) the example config in the SSSD tree uses min_id and max_id. I don't think it > should, the code enforces a different min_id value for local domain and > "regular" domains. > The example config issues are now tracked in https://fedorahosted.org/sssd/ticket/1014 > 2) now that shadow-utils defaults to min_id of 1000, we might consider bumping > up the local default to something bigger to avoid immediate clashes with shadow > users. We agreed not to bump up the default ID in the code, but just fix the example config instead.
Fixed upstream some time ago.