#1030 [RFE] Improve SASL authentication method negotiation
Closed: wontfix 4 years ago by pbrezina. Opened 12 years ago by sgallagh.

https://bugzilla.redhat.com/show_bug.cgi?id=743507

SASL authentication method is currently detected automatically the way that first method which is supported by both ldap server and client (sssd) is used.

However this might fail in some circumstances - example when communicating with Active Directory controllers. In this case there are three common SASL methods supported by both parties - SASL/EXTERNAL, SASL/GSSAPI and SASL/MD5 - so SASL/EXTERNAL is always used (being the first) - but it will almost certainly fail. It would be nice to attempt to connect via the rest of auth methods if the first one fails.

Note the workaround is simple as we can force the auth method via the 'ldap_sasl_mech' parameter - so please take this as suggestion only - does not have to be implemented at all.

Fields changed

coverity: =>
description: https://bugzilla.redhat.com/show_bug.cgi?id=743507

{{{
SASL authentication method is currently detected automatically the way that first method which is supported by both ldap server and client (sssd) is used.

However this might fail in some circumstances - example when communicating with Active Directory controllers. In this case there are three common SASL methods supported by both parties - SASL/EXTERNAL, SASL/GSSAPI and SASL/MD5 - so SASL/EXTERNAL is always used (being the first) - but it will almost certainly fail. It would be nice to attempt to connect via the rest of auth methods if the first one fails.

Note the workaround is simple as we can force the auth method via the 'ldap_sasl_mech' parameter - so please take this as suggestion only - does not have to be implemented at all.
}}}
=> https://bugzilla.redhat.com/show_bug.cgi?id=743507

{{{
SASL authentication method is currently detected automatically the way that first method which is supported by both ldap server and client (sssd) is used.

However this might fail in some circumstances - example when communicating with Active Directory controllers. In this case there are three common SASL methods supported by both parties - SASL/EXTERNAL, SASL/GSSAPI and SASL/MD5 - so SASL/EXTERNAL is always used (being the first) - but it will almost certainly fail. It would be nice to attempt to connect via the rest of auth methods if the first one fails.

Note the workaround is simple as we can force the auth method via the 'ldap_sasl_mech' parameter - so please take this as suggestion only - does not have to be implemented at all.
}}}

milestone: NEEDS_TRIAGE => SSSD 1.9.0
patch: => 0
rhbz: =>
tests: => 0
testsupdated: => 0
upgrade: => 0

Fields changed

summary: Improve SASL authentication method negotiation => [RFE] Improve SASL authentication method negotiation

Fields changed

blockedby: =>
blocking: =>
milestone: SSSD 1.9.0 => SSSD Deferred

Fields changed

feature_milestone: =>
milestone: SSSD Deferred => Temp milestone
proposed_priority: => Important

Moving all the features planned for 1.10 release into 1.10 beta.

milestone: Temp milestone => SSSD 1.10 beta

Fields changed

priority: minor => major

Fields changed

selected: => Not need

Moving tickets that are not a priority for SSSD 1.10 into the next release.

milestone: SSSD 1.10 beta => SSSD 1.11 beta

Fields changed

mark: => 0

I don't think there are any plans to support anything else than GSSAPI anytime soon.

changelog: =>
design: =>
design_review: => 0
fedora_test_page: =>
milestone: SSSD 1.13 beta => SSSD 1.13 backlog
priority: major => minor
review: => 0

Mass-moving tickets not planned for the next two releases.

Please reply with a comment if you disagree about the move..

milestone: SSSD 1.13 backlog => SSSD 1.15 beta

Metadata Update from @sgallagh:
- Issue set to the milestone: SSSD Future releases (no date set yet)

7 years ago

Metadata Update from @thalman:
- Custom field design_review reset (from 0)
- Custom field mark reset (from 0)
- Custom field patch reset (from 0)
- Custom field review reset (from 0)
- Custom field testsupdated reset (from 0)
- Issue close_status updated to: None
- Issue tagged with: Canditate to close

4 years ago

Thank you for taking time to submit this request for SSSD. Unfortunately this issue was not given priority and the team lacks the capacity to work on it at this time.

Given that we are unable to fulfill this request I am closing the issue as wontfix.

If the issue still persist on recent SSSD you can request re-consideration of this decision by reopening this issue. Please provide additional technical details about its importance to you.

Thank you for understanding.

Metadata Update from @pbrezina:
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)

4 years ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/2072

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata