RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 818642 - Auth fails for user with non-default attribute names
Summary: Auth fails for user with non-default attribute names
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: sssd
Version: 6.3
Hardware: Unspecified
OS: Unspecified
urgent
unspecified
Target Milestone: rc
: ---
Assignee: Stephen Gallagher
QA Contact: IDM QE LIST
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-05-03 15:47 UTC by Kaushik Banerjee
Modified: 2020-05-02 16:52 UTC (History)
3 users (show)

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.
Clone Of:
Environment:
Last Closed: 2012-06-20 11:56:52 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github SSSD sssd issues 2362 0 None None None 2020-05-02 16:52:41 UTC
Red Hat Product Errata RHBA-2012:0747 0 normal SHIPPED_LIVE sssd bug fix and enhancement update 2012-06-19 19:31:43 UTC

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
Note You need to log in before you can comment on or make changes to this bug.