Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 606922 - LDAP authentication against a referred user account fails
LDAP authentication against a referred user account fails
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: sssd (Show other bugs)
6.0
All Linux
low Severity medium
: rc
: ---
Assigned To: David O'Brien
Chandrasekar Kannan
: Documentation, Reopened
Depends On:
Blocks: 579775
  Show dependency treegraph
 
Reported: 2010-06-22 14:20 EDT by Gowrishankar Rajaiyan
Modified: 2015-01-04 18:42 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-11-11 11:29:56 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
sssd.conf (508 bytes, text/plain)
2010-06-22 14:25 EDT, Gowrishankar Rajaiyan
no flags Details

  None (edit)
Description Gowrishankar Rajaiyan 2010-06-22 14:20:16 EDT
Description of problem:
1. Enumeration fails for users through default referrals.
2. Enumeration for referred user hangs through smart referrals.

Version-Release number of selected component (if applicable):
# rpm -q sssd
sssd-1.2.1-15.el6.x86_64


How reproducible:


Steps to Reproduce for Default referral:
1. Configure default referral on ldap instance 1.
# cat add_ref_def.ldif 
dn: cn=config
changetype: modify
replace: nsslapd-referral
nsslapd-referral: ldap://shanksldap.idm.lab.bos.redhat.com:2636
----

# ldapmodify -x -h shanksldap.idm.lab.bos.redhat.com -p 389 -D "cn=Directory Manager" -w Secret123 -f /root/add_ref_def.ldif 
modifying entry "cn=config"
----

# ldapsearch -x -h shanksldap.idm.lab.bos.redhat.com -p 389 -D "cn=Directory Manager" -w Secret123 -b "cn=config" | grep shanksldap
nsslapd-referral: ldap://shanksldap.idm.lab.bos.redhat.com:2636
----

2. verifying the default referral 
# ldapsearch -x -h shanksldap.idm.lab.bos.redhat.com -p 389 -D "cn=Directory Manager" -w Secret123 -b "uid=user1000"
# extended LDIF
#
# LDAPv3
# base <uid=user1000> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# search result
search: 2
result: 10 Referral
ref: ldap://shanksldap.idm.lab.bos.redhat.com:2636

# numResponses: 1

3. Clear cache and restart sssd service.
4. Enumerate users
[root@shanks-rhel6 ~]# getent -s sss passwd 
auser1:*:1070:1070::/home/auser1:/bin/bash
puser1:*:1001:1001::/export/puser1:/bin/bash
puser2:*:1002:1002::/export/puser2:/bin/bash
puser3:*:999:999::/export/puser3:
sssd2:*:1006:1006::/export/sssd2:/bin/bash
sssd:*:1005:1005::/export/sssd:/bin/bash
[root@shanks-rhel6 ~]# getent -s sss passwd user1000
[root@shanks-rhel6 ~]#
  
Actual results:
user1000 is not enumerated.

/var/log/sssd/sssd_LDAP.log:
(Tue Jun 22 13:19:04 2010) [sssd[be[LDAP]]] [be_get_account_info] (4): Got request for [4097][1][name=user1000]
(Tue Jun 22 13:19:04 2010) [sssd[be[LDAP]]] [sdap_get_generic_send] (6): calling ldap_search_ext with [(&(uid=user1000)(objectclass=posixAccount))][dc=example,dc=com].
(Tue Jun 22 13:19:04 2010) [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [objectClass]
(Tue Jun 22 13:19:04 2010) [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [uid]
(Tue Jun 22 13:19:04 2010) [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [userPassword]
(Tue Jun 22 13:19:04 2010) [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [uidNumber]
(Tue Jun 22 13:19:04 2010) [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [gidNumber]
(Tue Jun 22 13:19:04 2010) [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [gecos]
(Tue Jun 22 13:19:04 2010) [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [homeDirectory]
(Tue Jun 22 13:19:04 2010) [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [loginShell]
(Tue Jun 22 13:19:04 2010) [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [krbPrincipalName]
(Tue Jun 22 13:19:04 2010) [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [cn]
(Tue Jun 22 13:19:04 2010) [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [modifyTimestamp]
(Tue Jun 22 13:19:04 2010) [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [shadowLastChange]
(Tue Jun 22 13:19:04 2010) [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [shadowMin]
(Tue Jun 22 13:19:04 2010) [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [shadowMax]
(Tue Jun 22 13:19:04 2010) [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [shadowWarning]
(Tue Jun 22 13:19:04 2010) [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [shadowInactive]
(Tue Jun 22 13:19:04 2010) [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [shadowExpire]
(Tue Jun 22 13:19:04 2010) [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [shadowFlag]
(Tue Jun 22 13:19:04 2010) [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [krbLastPwdChange]
(Tue Jun 22 13:19:04 2010) [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [krbPasswordExpiration]
(Tue Jun 22 13:19:04 2010) [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [pwdAttribute]
(Tue Jun 22 13:19:04 2010) [sssd[be[LDAP]]] [sdap_get_generic_send] (8): ldap_search_ext called, msgid = 6
(Tue Jun 22 13:19:04 2010) [sssd[be[LDAP]]] [sdap_process_result] (8): Trace: sh[0x739d90], connected[1], ops[0x810220], ldap[0x73a810]
(Tue Jun 22 13:19:04 2010) [sssd[be[LDAP]]] [sdap_get_generic_done] (6): Search result: Success(0), (null)
(Tue Jun 22 13:19:04 2010) [sssd[be[LDAP]]] [sdap_get_users_process] (6): Search for users, returned 0 results.
(Tue Jun 22 13:19:04 2010) [sssd[be[LDAP]]] [sdap_process_result] (8): Trace: sh[0x739d90], connected[1], ops[(nil)], ldap[0x73a810]
(Tue Jun 22 13:19:04 2010) [sssd[be[LDAP]]] [sdap_process_result] (8): Trace: ldap_result found nothing!
(Tue Jun 22 13:19:04 2010) [sssd[be[LDAP]]] [sysdb_search_entry_done] (6): Error: Entry not Found!
(Tue Jun 22 13:19:04 2010) [sssd[be[LDAP]]] [users_get_delete] (2): User (user1000) delete returned 2 (No such file or directory)
(Tue Jun 22 13:19:04 2010) [sssd[be[LDAP]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success


Expected results:
users from the default referred instance should get enumerated when queried using getent.


Steps to Reproduce for Smart referral:

1. Configure smart referral on ldap instance 1.

[root@shanks-rhel6 ~]# cat add_ref.ldif 
dn: uid=user1000,ou=People,dc=example,dc=com
changetype: add
objectclass: top
objectclass: extensibleObject
objectclass: referral
uid: user1000
ref: ldap://shanksldap.idm.lab.bos.redhat.com:2636/uid=user1000,ou=People,dc=bos,dc=redhat,dc=com
----

[root@shanks-rhel6 ~]# ldapmodify -x -h shanksldap.idm.lab.bos.redhat.com -p 389 -D "cn=Directory Manager" -w Secret123 -f /root/add_ref.ldif 
adding new entry "uid=user1000,ou=People,dc=example,dc=com"
----

2. Verify that smart referral works fine
[root@shanks-rhel6 ~]# ldapsearch -x -h shanksldap.idm.lab.bos.redhat.com -p 389 -D "cn=Directory Manager" -w Secret123 -b "uid=user1000,ou=People,dc=example,dc=com"
# extended LDIF
#
# LDAPv3
# base <uid=user1000,ou=People,dc=example,dc=com> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# search result
search: 2
result: 10 Referral
ref: ldap://shanksldap.idm.lab.bos.redhat.com:2636/uid=user1000,ou=People,dc=b
 os,dc=redhat,dc=com

# numResponses: 1
----

3. Clear cache and restart sssd service.
4. Enumerate user1000
[root@shanks-rhel6 ~]# getent -s sss passwd user1000
<hangs>

Actual result:
"getent -s sss passwd user1000" hangs on the console.

/var/log/sssd/sssd_LDAP.log:
(Tue Jun 22 13:25:38 2010) [sssd[be[LDAP]]] [sdap_get_generic_send] (6): calling ldap_search_ext with [(&(uid=*)(objectclass=posixAccount))][dc=example,dc=com].
(Tue Jun 22 13:25:38 2010) [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [objectClass]
(Tue Jun 22 13:25:38 2010) [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [uid]
(Tue Jun 22 13:25:38 2010) [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [userPassword]
(Tue Jun 22 13:25:38 2010) [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [uidNumber]
(Tue Jun 22 13:25:38 2010) [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [gidNumber]
(Tue Jun 22 13:25:38 2010) [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [gecos]
(Tue Jun 22 13:25:38 2010) [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [homeDirectory]
(Tue Jun 22 13:25:38 2010) [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [loginShell]
(Tue Jun 22 13:25:38 2010) [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [krbPrincipalName]
(Tue Jun 22 13:25:38 2010) [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [cn]
(Tue Jun 22 13:25:38 2010) [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [modifyTimestamp]
(Tue Jun 22 13:25:38 2010) [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [shadowLastChange]
(Tue Jun 22 13:25:38 2010) [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [shadowMin]
(Tue Jun 22 13:25:38 2010) [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [shadowMax]
(Tue Jun 22 13:25:38 2010) [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [shadowWarning]
(Tue Jun 22 13:25:38 2010) [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [shadowInactive]
(Tue Jun 22 13:25:38 2010) [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [shadowExpire]
(Tue Jun 22 13:25:38 2010) [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [shadowFlag]
(Tue Jun 22 13:25:38 2010) [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [krbLastPwdChange]
(Tue Jun 22 13:25:38 2010) [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [krbPasswordExpiration]
(Tue Jun 22 13:25:38 2010) [sssd[be[LDAP]]] [sdap_get_generic_send] (7): Requesting attrs: [pwdAttribute]
(Tue Jun 22 13:25:38 2010) [sssd[be[LDAP]]] [sdap_get_generic_send] (8): ldap_search_ext called, msgid = 4
(Tue Jun 22 13:25:38 2010) [sssd[be[LDAP]]] [sdap_process_result] (8): Trace: sh[0x25dfd90], connected[1], ops[0x26b67f0], ldap[0x25e0810]
(Tue Jun 22 13:25:38 2010) [sssd[be[LDAP]]] [sdap_process_result] (8): Trace: ldap_result found nothing!
(Tue Jun 22 13:25:38 2010) [sssd[be[LDAP]]] [sdap_process_result] (8): Trace: sh[0x25dfd90], connected[1], ops[0x26b67f0], ldap[0x25e0810]
(Tue Jun 22 13:25:38 2010) [sssd[be[LDAP]]] [sdap_parse_entry] (9): OriginalDN: [uid=puser2,ou=People,dc=example,dc=com].
(Tue Jun 22 13:25:38 2010) [sssd[be[LDAP]]] [sdap_process_result] (8): Trace: sh[0x25dfd90], connected[1], ops[0x26b67f0], ldap[0x25e0810]
(Tue Jun 22 13:25:38 2010) [sssd[be[LDAP]]] [sdap_parse_entry] (9): OriginalDN: [uid=puser3,ou=People,dc=example,dc=com].
(Tue Jun 22 13:25:38 2010) [sssd[be[LDAP]]] [sdap_process_result] (8): Trace: sh[0x25dfd90], connected[1], ops[0x26b67f0], ldap[0x25e0810]
(Tue Jun 22 13:25:38 2010) [sssd[be[LDAP]]] [sdap_parse_entry] (9): OriginalDN: [uid=puser1,ou=People,dc=example,dc=com].
(Tue Jun 22 13:25:38 2010) [sssd[be[LDAP]]] [sdap_process_result] (8): Trace: sh[0x25dfd90], connected[1], ops[0x26b67f0], ldap[0x25e0810]
(Tue Jun 22 13:25:38 2010) [sssd[be[LDAP]]] [sdap_parse_entry] (9): OriginalDN: [uid=sssd,ou=People,dc=example,dc=com].
(Tue Jun 22 13:25:38 2010) [sssd[be[LDAP]]] [sdap_process_result] (8): Trace: sh[0x25dfd90], connected[1], ops[0x26b67f0], ldap[0x25e0810]
(Tue Jun 22 13:25:38 2010) [sssd[be[LDAP]]] [sdap_parse_entry] (9): OriginalDN: [uid=sssd2,ou=People,dc=example,dc=com].
(Tue Jun 22 13:25:38 2010) [sssd[be[LDAP]]] [sdap_process_result] (8): Trace: sh[0x25dfd90], connected[1], ops[0x26b67f0], ldap[0x25e0810]
(Tue Jun 22 13:25:38 2010) [sssd[be[LDAP]]] [sdap_parse_entry] (9): OriginalDN: [uid=auser1,ou=People,dc=example,dc=com].
(Tue Jun 22 13:25:38 2010) [sssd[be[LDAP]]] [sdap_process_result] (8): Trace: sh[0x25dfd90], connected[1], ops[0x26b67f0], ldap[0x25e0810]
(Tue Jun 22 13:25:44 2010) [sssd[be[LDAP]]] [sdap_ldap_connect_callback_add] (9): New LDAP connection to [ldap://shanksldap.idm.lab.bos.redhat.com:2636/uid=user1000,ou=People,dc=bos,dc=redhat,dc=com] with fd [21].

Expected result:
referred user should be enumerated without hanging.

Additional info:
Comment 2 Gowrishankar Rajaiyan 2010-06-22 14:25:31 EDT
Created attachment 426041 [details]
sssd.conf
Comment 3 RHEL Product and Program Management 2010-06-22 14:32:56 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.
Comment 5 Stephen Gallagher 2010-06-29 13:09:04 EDT
Some portions of this bug report were found to be a misconfiguration of the server. However, we did identify one issue related to authentication. I'm updating the bug title to reflect this.

The SSSD stores the original DN of each user in the LDB cache when storing it. When we attempt to perform a simple bind, we use that originalDN attribute as the bind DN for the authentication.

However, in the case of referrals, we were storing the bind DN of the object on the referral server, not the one on the primary server. Since a referralis not required to have the same DN, this was resulting in a bind attempt against the wrong DN (in this specific case, it was against a nonexistent user since the referral pointed to an unrelated base DN)

We need to patch the caching code to store the correct originalDN.
Comment 6 Stephen Gallagher 2010-06-30 14:39:32 EDT
After much discussion upstream, this is being marked WONTFIX. There are unlikely to be any real-world deployments configured in exactly this way (with object-level referral instead of subtree-level referral).

The SSSD behaves properly with subtree-level referrals, so this is sufficient.
Comment 7 Jenny Galipeau 2010-07-08 11:36:55 EDT
reopening bug and assigning to david for documenting supported referrals.  will need info from sgallagh
Comment 8 David O'Brien 2010-07-23 02:20:18 EDT
(In reply to comment #7)
> reopening bug and assigning to david for documenting supported referrals.  will
> need info from sgallagh    

Apologies if this comes through twice; I clicked the wrong button.

This is a fairly complex (for me) bug/behaviour, so I'll need as much info as possible to produce sensible doc. If you use the "Cause, Consequence, Fix, Result" approach, or something like it, we should be able to cover all the bases.

Thanks a lot.
Comment 9 Stephen Gallagher 2010-07-29 14:20:00 EDT
Here are the kinds of LDAP referrals that the SSSD can handle properly.

The first kind is object-level referrals within the same LDAP server. This means that if we requested uid=user1,ou=People,dc=example,dc=com and the LDAP server was configured to return a referral within the same server to e.g. uid=user1,ou=People,dc=local,dc=example,dc=com, then we would support this.

Object-level referrals *between* LDAP servers can only be supported by SSSD if the full distinguished names are identical (the referral only directs it to a different server, it doesn't point to a different DN path on that server)


The second kind of referral is the subtree referral. Similar to the object-level referrals, we can only support referrals that either point to a changed DN on the local system or the exact same DN on a remote system.


The most common subtree referral case (indeed the most common referral case) would be the following.

Consider a company with offices in several locations (we'll use Boston and Sydney for example).

This company might set up their LDAPHere are the kinds of LDAP referrals that the SSSD can handle properly.

The first kind is object-level referrals within the same LDAP server. This means that if we requested uid=user1,ou=People,dc=example,dc=com and the LDAP server was configured to return a referral within the same server to e.g. uid=user1,ou=People,dc=local,dc=example,dc=com, then we would support this.

Object-level referrals *between* LDAP servers can only be supported by SSSD if the full distinguished names are identical (the referral only directs it to a different server, it doesn't point to a different DN path on that server)


The second kind of referral is the subtree referral. Similar to the object-level referrals, we can only support referrals that either point to a changed DN on the local system or the exact same DN on a remote system.


The most common subtree referral case (indeed the most common referral case) would be the following.

Consider a company with offices in several locations (we'll use Boston and Sydney for example).

This company sets up two LDAP servers, one in the Boston office configured to store the local Boston accounts and one in the Sydney office to store those accounts.

So the Boston LDAP server would have its users stored like:
uid=bostonuser1,ou=boston,ou=People,dc=example,dc=com
It would also have a subtree referral like
out=sydney,ou=People,dc=example,dc=com that would point to the Sydney server.

This way, if user information was requested for a Sydney user (rare) in this case the request would be redirected to the server in Sydney to answer it authoritatively. The reverse would be similarly set up on the Sydney server.

I hope this clarifies it for you.
Comment 10 David O'Brien 2010-08-01 21:58:47 EDT
Applying BZ 606922; add sub-section on referral support in SSSD to RHEL 6 Deployment Guide

15.2.2.4. Support for LDAP Referrals

f9c8cce..ba46d42  master -> master
Comment 11 David O'Brien 2010-08-02 01:48:20 EDT
Added some extra info from Trac #383

ba46d42..784e8d9  master -> master
Comment 12 Gowrishankar Rajaiyan 2010-08-16 15:36:21 EDT
15.2.2.4.3. Enabling LDAP Referrals:

/etc/sssd.conf should  be /etc/sssd/sssd.conf
Comment 13 David O'Brien 2010-08-16 20:37:59 EDT
Fixed.

069e47b..bbd3205  master -> master
Comment 14 Gowrishankar Rajaiyan 2010-08-20 01:27:00 EDT
Verified in 15.2.2.4.3. Enabling LDAP Referrals.
Comment 15 releng-rhel@redhat.com 2010-11-11 11:29:56 EST
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.

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