Bug 606922 - LDAP authentication against a referred user account fails
Summary: LDAP authentication against a referred user account fails
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: sssd
Version: 6.0
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: David O'Brien
QA Contact: Chandrasekar Kannan
URL:
Whiteboard:
Keywords: Documentation, Reopened
Depends On:
Blocks: 579775
TreeView+ depends on / blocked
 
Reported: 2010-06-22 18:20 UTC by Gowrishankar Rajaiyan
Modified: 2015-01-04 23:42 UTC (History)
5 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2010-11-11 16:29:56 UTC


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

Description Gowrishankar Rajaiyan 2010-06-22 18:20:16 UTC
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 18:25:31 UTC
Created attachment 426041 [details]
sssd.conf

Comment 3 RHEL Product and Program Management 2010-06-22 18:32:56 UTC
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 17:09:04 UTC
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 18:39:32 UTC
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 15:36:55 UTC
reopening bug and assigning to david for documenting supported referrals.  will need info from sgallagh

Comment 8 David O'Brien 2010-07-23 06:20:18 UTC
(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 18:20:00 UTC
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-02 01:58:47 UTC
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 05:48:20 UTC
Added some extra info from Trac #383

ba46d42..784e8d9  master -> master

Comment 12 Gowrishankar Rajaiyan 2010-08-16 19:36:21 UTC
15.2.2.4.3. Enabling LDAP Referrals:

/etc/sssd.conf should  be /etc/sssd/sssd.conf

Comment 13 David O'Brien 2010-08-17 00:37:59 UTC
Fixed.

069e47b..bbd3205  master -> master

Comment 14 Gowrishankar Rajaiyan 2010-08-20 05:27:00 UTC
Verified in 15.2.2.4.3. Enabling LDAP Referrals.

Comment 15 releng-rhel@redhat.com 2010-11-11 16:29:56 UTC
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.