Bug 818642 - Auth fails for user with non-default attribute names
Auth fails for user with non-default attribute names
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: sssd (Show other bugs)
6.3
Unspecified Unspecified
urgent Severity unspecified
: rc
: ---
Assigned To: Stephen Gallagher
IDM QE LIST
: Regression
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-05-03 11:47 EDT by Kaushik Banerjee
Modified: 2012-06-20 07:56 EDT (History)
3 users (show)

See Also:
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 07:56:52 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Kaushik Banerjee 2012-05-03 11:47:30 EDT
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 11:56:46 EDT
Upstream ticket:
https://fedorahosted.org/sssd/ticket/1320
Comment 6 Kaushik Banerjee 2012-05-16 06:49:35 EDT
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 08:35:20 EDT
    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 07:56:52 EDT
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

Note You need to log in before you can comment on or make changes to this bug.