Bug 741164

Summary: sssd user fails to ssh to localhost with min_uid=500 (aka defaults)
Product: [Fedora] Fedora Reporter: Kashyap Chamarthy <kchamart>
Component: sssdAssignee: Stephen Gallagher <sgallagh>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 16CC: dpal, jhrozek, sbose, sgallagh, ssorce
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-03-05 16:14:06 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Kashyap Chamarthy 2011-09-26 02:20:16 EDT
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
Comment 1 Jakub Hrozek 2011-09-26 04:28:36 EDT
(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.
Comment 2 Jakub Hrozek 2011-09-29 11:17:37 EDT
(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.
Comment 3 Stephen Gallagher 2012-03-05 16:14:06 EST
Fixed upstream some time ago.