Bug 818642

Summary:	Auth fails for user with non-default attribute names
Product:	Red Hat Enterprise Linux 6	Reporter:	Kaushik Banerjee <kbanerje>
Component:	sssd	Assignee:	Stephen Gallagher <sgallagh>
Status:	CLOSED ERRATA	QA Contact:	IDM QE LIST <seceng-idm-qe-list>
Severity:	unspecified	Docs Contact:
Priority:	urgent
Version:	6.3	CC:	grajaiya, jgalipea, prc
Target Milestone:	rc	Keywords:	Regression
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	sssd-1.8.0-26.el6	Doc Type:	Bug Fix
Doc Text:	Cause: When reading data about a user for use in authentication, in several places we were expecting the default attribute name to be used. Consequence: If a user's data was specified in non-standard LDAP attributes, they would fail authentication. Fix: The code was updated to properly use the configured attributes instead of the default values. Result: Authentication of users now works when they are configured with non-standard attributes.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-06-20 11:56:52 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Kaushik Banerjee 2012-05-03 15:47:30 UTC

Description of problem:
Auth fails for user with non-default attribute names

Version-Release number of selected component (if applicable):
1.8.0-25

How reproducible:
Always

Steps to Reproduce:
1.Setup openldap server with non-default attributes.

2. Add a user, group with non-default attributes:
dn: uid=nd_user1,dc=example,dc=com
objectClass: account
objectClass: posixAccount1
cn1: nd_user1
uid1: nd_user1
uidNumber1: 12321
gidNumber1: 12321
homeDirectory1: /home/nd_user1
loginShell1: /bin/bash
gecos1: NONDEFAULT USER1
userPassword: Secret123
 
dn: cn=nd_user1_grp1,dc=example,dc=com
gidNumber1: 12321
cn1: nd_user1_grp1
objectClass: posixGroup1
objectClass: extensibleObject
memberUid1: nd_user1
 
3. Setup sssd.conf domain section as follows:

[domain/LDAP]
id_provider = ldap
ldap_uri = ldap://ldapsrv.example.com
ldap_search_base = dc=example,dc=com
debug_level = 0xFFF0
ldap_tls_cacert = /etc/openldap/certs/server.pem
ldap_user_object_class = posixAccount1
ldap_user_name = uid1
ldap_user_uid_number = uidNumber1
ldap_user_gid_number = gidNumber1
ldap_user_gecos = gecos1
ldap_user_home_directory = homeDirectory1
ldap_user_shell = loginShell1
ldap_group_object_class = posixGroup1
ldap_group_gid_number = gidNumber1
ldap_group_member = memberUid1
 
4. Lookup user and group:
# getent -s sss passwd nd_user1
nd_user1:*:12321:12321:NONDEFAULT USER1:/home/nd_user1:/bin/bash
 
# getent -s sss group nd_user1_grp1
nd_user1_grp1:*:12321:nd_user1
 
# id nd_user1
uid=12321(nd_user1) gid=12321(nd_user1_grp1) groups=12321(nd_user1_grp1)
 

5. Try to auth as the user  
# ssh -l nd_user1 localhost
nd_user1@localhost's password:
Permission denied, please try again.
nd_user1@localhost's password: 


Actual results:
Auth fails

Expected results:
Auth should succeed

Additional info:
1. /var/log/sssd/sssd_LDAP.log shows:
(Thu May  3 19:56:22 2012) [sssd[be[LDAP]]] [sdap_save_users] (0x4000): User 0 processed!
(Thu May  3 19:56:22 2012) [sssd[be[LDAP]]] [sdap_check_aliases] (0x2000): Could not get UID
(Thu May  3 19:56:22 2012) [sssd[be[LDAP]]] [sdap_save_users] (0x0040): Failed to check aliases for user 0. Ignoring.
(Thu May  3 19:56:22 2012) [sssd[be[LDAP]]] [ldb] (0x4000): commit ldb transaction (nesting: 0)
(Thu May  3 19:56:22 2012) [sssd[be[LDAP]]] [sdap_get_users_process] (0x4000): Saving 1 Users - Done

2. /var/log/secure shows:
May  3 19:55:22 dhcp201-132 sshd[8533]: pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=localhost user=nd_user1
May  3 19:55:22 dhcp201-132 sshd[8533]: pam_sss(sshd:auth): received for user nd_user1: 10 (User not known to the underlying authentication module)
May  3 19:55:24 dhcp201-132 sshd[8533]: Failed password for nd_user1 from ::1 port 48696 ssh2

Comment 1 Stephen Gallagher 2012-05-03 15:56:46 UTC

Upstream ticket:
https://fedorahosted.org/sssd/ticket/1320

Comment 6 Kaushik Banerjee 2012-05-16 10:49:35 UTC

Verified in version sssd-1.8.0-27


Output of automation run:
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:: [   LOG    ] :: non-default-attribute_001: enumerate user and group and auth
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::

adding new entry "uid=nd_user1,dc=example,dc=com"

adding new entry "cn=nd_user1_grp1,dc=example,dc=com"

:: [   PASS   ] :: Running 'ldapadd -x -H ldap://dell-pesc1425-01.rhts.eng.bos.redhat.com -D "cn=Manager,dc=example,dc=com" -w Secret123 -f /tmp/non-default-user1.ldif'
12321
:: [   PASS   ] :: Running 'getent -s sss passwd nd_user1 | awk -F: '{print $3}' | grep 12321'
12321
:: [   PASS   ] :: Running 'getent -s sss passwd nd_user1 | awk -F: '{print $4}' | grep 12321'
NONDEFAULT USER1
:: [   PASS   ] :: Running 'getent -s sss passwd nd_user1 | awk -F: '{print $5}' | grep "NONDEFAULT USER1"'
/home/nd_user1
:: [   PASS   ] :: Running 'getent -s sss passwd nd_user1 | awk -F: '{print $6}' | grep /home/nd_user1'
/bin/bash
:: [   PASS   ] :: Running 'getent -s sss passwd nd_user1 | awk -F: '{print $7}' | grep /bin/bash'
nd_user1_grp1:*:12321:nd_user1
:: [   PASS   ] :: Running 'getent -s sss group nd_user1_grp1'
nd_user1_grp1
:: [   PASS   ] :: Running 'id -gn nd_user1 | grep nd_user1_grp1'
spawn ssh -q -l nd_user1 localhost echo 'login successful'
nd_user1@localhost's password: 
Could not chdir to home directory /home/nd_user1: No such file or directory
login successful
:: [   PASS   ] :: Authentication successful, as expected
:: [   PASS   ] :: Running 'auth_success nd_user1 Secret123'
'37fb6325-4085-4d9d-9c48-8e7b9031cdce'
non-default-attribute-001 result: PASS

Comment 7 Stephen Gallagher 2012-06-12 12:35:20 UTC

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Cause: When reading data about a user for use in authentication, in several places we were expecting the default attribute name to be used.

Consequence: If a user's data was specified in non-standard LDAP attributes, they would fail authentication.

Fix: The code was updated to properly use the configured attributes instead of the default values.

Result: Authentication of users now works when they are configured with non-standard attributes.

Comment 9 errata-xmlrpc 2012-06-20 11:56:52 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2012-0747.html