Bug 606922
| Summary: | LDAP authentication against a referred user account fails | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Gowrishankar Rajaiyan <grajaiya> | ||||
| Component: | sssd | Assignee: | David O'Brien <nobody+davido> | ||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Chandrasekar Kannan <ckannan> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | low | ||||||
| Version: | 6.0 | CC: | benl, daobrien, dpal, jgalipea, sgallagh | ||||
| Target Milestone: | rc | Keywords: | Documentation, Reopened | ||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2010-11-11 16:29:56 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 579775 | ||||||
| Attachments: |
|
||||||
|
Description
Gowrishankar Rajaiyan
2010-06-22 18:20:16 UTC
Created attachment 426041 [details]
sssd.conf
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. 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. 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. reopening bug and assigning to david for documenting supported referrals. will need info from sgallagh (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. 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. 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 Added some extra info from Trac #383 ba46d42..784e8d9 master -> master 15.2.2.4.3. Enabling LDAP Referrals: /etc/sssd.conf should be /etc/sssd/sssd.conf Fixed. 069e47b..bbd3205 master -> master Verified in 15.2.2.4.3. Enabling LDAP Referrals. 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. |