Learn more about these different git repos.
Other Git URLs
When negotiating encryption using either StartTLS or during the initial setup of an LDAPS connection, the client may be offered the opportunity to offer up its own certificate in order to authenticate to the directory server as part of the handshake.
Some servers will allow the client to subsequently "authenticate" using SASL/EXTERNAL and then proceed as an authenticated client. Since we support SASL/GSSAPI and simple binds, we should probably add the necessary plumbing to let SSSD authenticate this way, too.
Fields changed
component: SSSD => LDAP Provider
milestone: NEEDS_TRIAGE => SSSD 1.6.0 version: => 1.2.1
coverity: => milestone: SSSD 1.6.0 => SSSD 1.7.0 upgrade: => 0
To clarify, this is something along the lines of using the client system's certificate and private key to authenticate as part of the TLS or SSL handshake. SASL/EXTERNAL should (hopefully?) be available as an option to instruct the server to authorize the client to use the directory based on naming information present in the client certificate (by mapping the subject DN to an entry in the directory, or by pulling out a subjectAltName value and using that, or something else).
milestone: SSSD 1.8.0 => SSSD 1.9.0 patch: => 0
blockedby: => blocking: => milestone: SSSD 1.9.0 => SSSD Deferred rhbz: =>
rhbz: => 0
feature_milestone: => proposed_priority: => Important
priority: minor => critical
milestone: SSSD Deferred => SSSD 1.10.0
proposed_priority: Important => Core
Hmm, at least some of this appears to have been done as part of ticket #780.
SSSD may need to be able to diagnose cases where the client's certificate is no longer valid, or at least have someone else (e.g., certmonger) watching out for that eventuality.
In at least some cases, the system which is running the directory server that SSSD is contacting will also be running a CA provided by the directory server's vendor. While certmonger can already handle that when the directory server and CA are IPA, SSSD also runs in other environments. We're going to teach certmonger to [talk to standalone Dogtag instances], and also look at teaching it to https://fedorahosted.org/certmonger/ticket/11 talk to ADCS. You may want to make use of that capability if/when it becomes available.
I don't know if that means a new ticket of some sort for SSSD, so I'm just making a note here so it won't come as a complete surprise later.
rhbz: 0 => todo summary: Add support for certificate-based authentication to directory servers => [RFE] Add support for certificate-based authentication to directory servers
Cleaning the 1.10 milestones before putting tickets into it.
milestone: SSSD 1.10.0 => Temp milestone
Moving planned features and bug fixes into the 1.10 bucket.
milestone: Temp milestone => SSSD 1.10.0
Moving all the features planned for 1.10 release into 1.10 beta.
milestone: Temp milestone => SSSD 1.10 beta
design: => design_review: => 0 fedora_test_page: => 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
priority: critical => minor
mark: => 0
changelog: => milestone: SSSD 1.13 beta => SSSD 1.13 backlog 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
Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=1292505 (Red Hat Enterprise Linux 7)
rhbz: todo => [https://bugzilla.redhat.com/show_bug.cgi?id=1292505 1292505]
Metadata Update from @nalin: - Issue set to the milestone: SSSD Future releases (no date set yet)
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
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)
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/1603
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.